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The present invention provides a communi- 
cations system, and method of operation of 
such a system, for facilitating exchange of data 
between a first computer and a second com- 
puter connected in a network to operate in a 
client/server arrangement, the first computer 
employing a different operating system to the 
second computer, and the system having a 
basic communications application program in- 
terface (API). The system is characterised by: 
first logic means for processing requests from a 
first application running on the first computer 
for connection with the second computer to 
carry out one of a plurality of communication 
services; second logic means for instructing a 
second application on the second computer to 
carry out the communications services and for 
returning data provided by the second appli- 
cation to the first computer; and a storage 
device on each computer accessible by the 
respective logic means and storing a single 
object dass for providing definitions for each of 
the plurality of communication services. 

The realisation that the various different com- 
munications services can be represented by a 



single Object Class has given rise to a number 
of significant improvements in client/server 
communications, and has enabled the commu- 
nications domain (the services of the class and 
its derived classes) to be dearly defined. 
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The present invention relates to a communica- 
tions system, and method of operation of such a sys- 
tem, for facilitating exchange of data between two or 
more computers connected in a network. In particular 
the communications system is based on a Client/Ser- 5 
ver model, and in a typical Client/Server model there 
will be periodic communication between an applica- 
tion program at a Client computer and a Server com- 
puter connected across the network. The Client com- 
puter will usually be close to the human user of the 10 
system and the Server computer will typically provide 
a variety of central services. 

The client and server computer architectures are 
frequently heterogeneous in terms of the manner in 
which data is represented and tasks are managed. By 15 
its nature, the server computer operating system may 
also be very complex (eg IBM's MVS Operating Sys- 
tem) and require deep knowledge of the system struc- 
ture and facilities to operate with adequate perfor- 
mance and also with adequate reliability, availability 20 
and serviceability (commonly known as RAS), which 
are essential if the user at the client system is to be 
serviced adequately. 

The communications system will provide the 'in- 
terface' between the Client computer and the Server 25 
computer, and a programmer writing the client appli- 
cation program will utilise this interface to communi- 
cate a wide range of basic requests and responses 
between the client and the server. On top of these ba- 
sic requests, higher level requests related specif ical- 30 
ly to the client application may need to be implement- 
ed. 

There are a variety of known techniques for es- 
tablishing interfaces which facilitate, to a degree, co- 
operative processing between a client and server 35 
computer. These techniques depend to a greater or 
lesser extent on the underlying communications pro- 
tocol, such as the APPC (or LU6.2) or TCP/IP proto- 
col. 

One known programming interface is the basic 40 
Communications Interface, eg APPC. As will be 
known by the person skilled in the art, APPC gives an 
"Application Program Interface" (API) access into the 
large set of LU6.2 facilities, including architectu- 
ral 'towers' for such things as the Distributed Data 45 
Model. Other communications protocols (eg TCP/IP) 
provide alternative facilities. 

Although each Client application program can de- 
velop its own implementation on top of APPC, this re- 
sults in a duplication of effort and education in a par- so 
ticularly complex area and makes full code reusabil- 
ity more difficult, since the boundaries of the use of 
the interface are not pre-defined. 

An efficient implementation for the majority of cli- 
ent/server needs ought to be such that it avoids the 55 
need for the client application programmer to have a 
deep understanding of communications protocols 
such as LU6.2. 



Another known programming interface is provid- 
ed by the Remote Procedure Call (RPC). With this fa- 
cility, the client application programmer merely calls 
subroutines to access remote facilities such as a da- 
tabase, and the communication system takes care of 
recognising whether the subroutine is local or remote. 
In the remote case the call is packaged and sent on 
a link (eg. an LU6.2 link) to the remote system. Since 
the client application is unaware of this 'function- 
shipping' it waits until the call returns. 

This RPC technique fails to be sufficiently flex- 
ible for the needs of today's powerful client/server 
systems. It does not possess the flexibility to enable 
other processing to be carried out before the reply is 
received, and can be complex to implement due to the 
need to maintain transparency of the link. 

This type of interface is totally 'transparent', in 
that the programmer is completely unaware that com- 
munications to a remote computer are taking place; 
this is not ideal where it is desired that the client/ser- 
ver system should optimise its performance and us- 
ability. In such instances it is important that the client 
application programmer can choose the type of re- 
quest (Remote Procedure Call, File Transfer, etc) in 
a non-transparent way, so that, when a server access 
is required, the programmer can make the best deci- 
sion as to the type of request that will not impact the 
end-user unduly. 

In Message Driven Processing techniques, the 
application interface (such as provided by 
IBM's 'MQSeries' range of products) provides full 
asynchronous, queued communication between dis- 
tributed applications. Distributed applications are ap- 
plications which reside partly on two or more comput- 
ers, these parts needing to communicate with each 
other. The application interface provides comprehen- 
sive message delivery, which is suitable for Workflow 
Management, and complex recovery and integrity. 

Other, simpler, methods of communication using 
messages between distributed applications also ex- 
ist, particularly in the workstation only environment. 

The more complex message driven processing 
techniques (such as the full MQSeries solution), are 
not appropriate and too 'expensive' for a tightly-cou- 
pled cooperative application. Such an application is 
one where the separate parts running on different 
computers know when they should talk and listen to 
one another. One example is a dedicated client/ser- 
ver communication system. Here the client asks the 
server a question and the server answers; the server 
never talks to the client unless a question is asked. In 
such applications there is no need for asynchronous 
queuing, since the client makes a request and the ser- 
ver services it straight away. 

On the other hand, the simpler messaging meth- 
ods are not readily available on host systems such as 
MVS, which are required for today's powerful cli- 
ent/server facilities (including unlimited access to 



3 



3 



EP 0 677 943 A2 



4 



host databases and performance). 

Another known technique is commonly 
called "Local API Emulation*. Various Cooperative 
programming Interfaces rely on emulating some or all 
of the 'local* API; this technique can be viewed as a 
type of enhanced RPC. For instance, 
IBM's 'AConnS* product provided cooperative func- 
tions by a distributed version of a subset of the OS/2 
Presentation Manager Interface. An advantage over 
the standard RPC technique is that the programmer 
of the client application is explicitly aware that com- 
munication is in progress, and so can optimise his/her 
activities. However a disadvantage is that distribution 
of a complex local API can prove unwieldy, costly, and 
unnatural. Further, the API concepts that are distrib- 
uted may be too broad or too far removed from the 
specific needs of Client/Server systems. 

Nowadays many data processing systems have a 
message based environment in which 'object instanc- 
es' are created and utilised by applications running 
on the system. 

A message based environment is used by Object 
Oriented Programming (OOP) techniques, OOP be- 
ing a particular approach to software development 
which implements required functions by way of 'mes- 
sages' sent to 'objects'. An 'object' is a software 
component that contains a collection of related proce- 
dures (hereafter called 'methods') and data. Further 
objects can be grouped into 'Object Classes', an ob- 
ject class being a template for defining the methods 
and data for a particular type of object. All objects of 
a given class are identical in form and behaviour but 
have different data associated with them. 

A 'message' is a signal sent to an object to re- 
quest the object to carry out one of its methods. 
Hence a message sent to an object will cause a meth- 
od to be invoked to implement the required function. 

It is now becoming more common for OOP tech- 
niques to be applied in the programming interface 
area. In object-oriented design, the first task is to 
identify the 'domains' - such as the application (real 
world), the user interface, the system services, and 
possibly communications. It is difficult to clearly de- 
marcate these. 

The second task is to identify the classes (ob- 
jects with their attributes and associated services) 
within each domain. The complexity of the resultant 
software is crucially dependent on this analysis. 

Prior art systems that use objects to represent 
the communications facilities typically end up with a 
set of unrelated objects, driven by the need to reflect 
an existing API (eg APPC). As a result, the boundaries 
of the Communications Domain are usually not clear- 
ly identifiable. For example, a typical OOP system 
might implement the communications facilities such 
as "Start-Session", "Get-Buffers'*, "Send/Receive", 
"Error-Response", and "Data-Purge" as unrelated ob- 
jects, which are very much tied to the application pro- 



gram that they were developed for. Hence it is difficult 
to re-use them. 

In the Client/Server environment, there is a need 
for a programming interface between the client and 

5 the server to provide the major client/server facilities, 
for example.allowing the local client application to call 
functions, manipulate files, transfer data and conduct 
conversational communications with remote server 
platforms, without exposure of the client application 

10 to the communications architecture or communica- 
tions API. 

Advantageously this should operate in such a 
way that it can be optimised for Client/Server, take 
advantage of complex high-power host systems, and 

15 support heterogeneous data representations, etc. be- 
tween client and server. 

Further the communications system embodying 
the interface should, in preferred embodiments, be 
reusable for other varieties of Client/Server, and ex- 

20 tendible, for example, to other server platforms. 

Accordingly the present invention provides a 
communications system for facilitating exchange of 
data between a first computer and a second comput- 
er connected in a network to operate in a client/server 

25 arrangement, the first computer employing a different 
operating system to the second computer, and the 
system having a basic communications application 
program interface (API), the system being character- 
ised by: first logic means for processing requests 

30 from a first application running on the first computer 
for connection with the second computer to carry out 
one of a plurality of communication services; second 
logic means for instructing a second application on 
the second computer to carry out the communica- 

35 tions services and for returning data provided by the 
second application to the first computer; and a stor- 
age device on each computer accessible by the re- 
spective logic means, each storage device storing a 
single object class for providing definitions for each of 

40 the plurality of communication services. 

In preferred embodiments each storage device 
stores a cohesive framework of object classes de- 
rived from the single object class. Further the commu- 
nications services defined by the framework of object 

45 classes typically facilitate function calling, file manip- 
ulation, and data transfer. 

In the preferred embodiment of the communica- 
tions system, the operating system employed by the 
first computer is the IBM OS/2 operating system. Fur- 
so ther the operating system employed by the second 
computer is the IBM MVS operating system. With 
such an arrangement, the basic communications API 
can be APPC. 

Viewed from a second aspect, the present inven- 

55 tion provides a method of operating a communication 
system to facilitate exchange of data between a first 
computer and a second computer connected in a net- 
work to operate in a client/server arrangement, the 
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first computer employing a different operating system 
to the second computer, and the system having a ba- 
sic communications application program interface 
(API), the method being characterised by the steps of: 
employing a first logic means to process requests 5 
from a first application running on the first computer 
for connection with the second computer to carry out 
one of a plurality of communication services; employ- 
ing a second logic means to instruct a second appli- 
cation on the second computer to carry out the com- 10 
munications services; returning data provided by the 
second application via the second logic means to the 
first computer; and storing in each computer in a stor- 
age region accessible by the respective logic means 
a single object class for providing definitions for each 15 
of the plurality of communication services. 

The invention resides in the realisation that the 
different communication services can be represented 
by a single 'Object Class 1 , this approach giving rise to 
a number of significant improvements in client/server 20 
communications. By proposing that 'Communica- 
tions' (Client<->Server) can 'itself be represented 
as a CLASS, the communications domain (the servic- 
es of the class and its derived classes) can be clearly 
defined. 25 

The technique of the present invention, unlike 
any of the prior art techniques described above, pro- 
vides a definitive, reusable, set of client/server facili- 
ties within the API itself. 

Normally, the problem when providing 'gener- 30 
ic' services is that it is not readily possible to optimise 
for specific environments and also allow easy change 
or enhancement of the functionality for specific appli- 
cation needs. 

Clearly code which operates in the Communica- 35 
tions Domain can always be written in an object-ori- 
ented manner (since any code can in theory be writ- 
ten in an object-oriented manner), but it is the crux of 
this invention that, by representing the essential set 
of Client/Server communication facilities as a single 40 
C++ Object Class themselves, a flexible and simple 
interface can be constructed. In other words, the in- 
vention encapsulates a new technique for establish- 
ing an extremely usable cooperative interface for cli- 
ent/server applications. 45 

This technique arises from the idea of regarding 
the client/server cooperative needs as attributes of a 
class, in combination with the utilisation of object-ori- 
ented concepts (eg class derivation allows easy 
changes and extensions to the base functions, so that so 
the interface is tailored to the specific requirements 
of the system). 

By representing the services of RPC, File Trans- 
fer, Data Conversion, Send/Receive, etc as class ser- 
vices, communications is no more complex than a 55 
normal function call, but is extendible and optimisable 
without affecting its fundamental nature; the class 
can be extended or sub-classed without affecting any 



existing uses. Further, it is eminently reusable, as 
new classes can be derived for new client/server ap- 
plications. 

The present invention will be described further, 
by way of example only, with reference to a preferred 
embodiment of the invention as illustrated in the ac- 
companying drawing, in which: 

Figure 1 is a block diagram illustrating the com- 
munications system of the preferred embodiment of 
the present invention. 

In the preferred embodiment of the present inven- 
tion, we will consider a communications system that 
is based on a typical client/server model. The client 
computer will typically employ an operating system 
such as IBM's OS/2 operating system, and the server 
computer will employ a host-based operating system 
such as IBM's MVS operating system (IBM, OS/2 and 
MVS are Trade Marks of International Business Ma- 
chines Corporation). 

The problem in constructing a communications 
system can generally be separated into specific 
areas. In order to do this one must firstly consider the 
specific functional requirements of the communica- 
tions system in question. For instance, a number of 
specific functional requirements for the communica- 
tions system may be: 

RPC : Essentially, the communications system 
will invoke a procedure on the Host Server, at the re- 
quest of the Client. Although the initial number of pos- 
sible procedures may be relatively small, this facility 
should be easily extensible for adding new proce- 
dures in the future. 

Data Conversion : The communications system 
may have a large number of complex control blocks, 
consisting of mixed data types, to be exchanged be- 
tween the Client and the Host Server. These will have 
to converted into the appropriate platform formats, 
and may have to accommodate DBCS (Double Byte 
Character Set) data, such as Kanji. 

Buffer Management There will be arbitrarily 
sized amounts of data returned from the Server, and 
the amount of data to be returned is not known in ad- 
vance. It may be large, in excess of the send buffer 
limit (the send buffer is the storage area for data being 
sent on the link). 

File Management : Download and upload of files 
including sequential & PDS (Partitioned Data Set) 
members may be required. There are other potential 
requirements such as delete, print, copy, etc. 

Transparent Operation : For the usability goals of 
the communications system, the communications as- 
pects should be 'unseen'. The need for user initiated 
start-up and termination is to be avoided. 

Flexibility : As the communications system may 
be usable on widely differing system configurations, 
the significant performance factors may vary consid- 
erably. It should be easy to amend the key perfor- 
mance parameters to accommodate this. However, it 
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should also provide a default configuration for ease of 
use. 

Environment : In the preferred embodiment of the 
present invention the communications system re- 
quires the above functionality between an OS/2 client 5 
and MVS server using APPC communications. 

These requirements give rise to a number of sep- 
arate problems. For instance one problem is in Per- 
formance & Resource Use - the User driven, multi- 
threaded nature of OS/2 in particular presents a num- 10 
ber of problems for Client/Server to MVS, for exam- 
ple: 

1. Concurrency: Concurrent Server activities are 
needed to handle concurrent front end activities 

if response time is to be acceptable. This is es- is 
pecially difficult with an MVS server; 

2. Session Control: Unpredictable user activity 
sequence cannot determine how long to keep 
communications sessions active. Frequent stop- 
ping & starting of sessions carries a heavy per- 20 
formance overhead; 

3. Resource Use: Unless attempts are made to 
maximise the effective use of resources such as 
OS/2 processes, MVS address spaces & APPC 
conversations, concurrent activity on the work- 25 
station could cause heavy use of the various net- 
work and platform resources. This translates into 

high cost and less overall processing capability; 
and 

4. Resource Sharing: Unless attempts are made 30 
to manage the use of resources, heavy activity by 

one user could adversely affect the resources 
available to other users, and thus impact on their 
application's performance. Ideally, heavy activity 
by one user should only impact their own perfor- 35 
mance. 

A second problem that arises is in the area of 
Software Reuse & Extensibility. The functionality de- 
veloped for the communications system should be 
easy to use, re-use, and extend. This is to accommo- 40 
date the following potential uses: 

1. Future extensions to the communications sys- 
tem, such as additional functionality and new 
platforms (eg. VM); and 

2. Re-use of the communications system as 45 
a 'building block' for other products. 

These problems have been overcome in the pre- 
ferred embodiment of the present invention by con- 
structing a single, cohesive and unified 'product 1 , 
which provides the required communications require- 50 
ments as to functionality and performance, as well as 
being easily extendable and tailorable. This product is 
referred to hereafter as the Client/Server Application 
Enabler (CSAE). Its characteristics are: 

1 . It provides services to a client application to al- 55 
low the client application to call functions, manip- 
ulate files, transfer data and conduct conversa- 
tional communications with remote platforms, 



without exposure of the client application to the 
communications architecture or communications 
API. 

2. It presents these services as a cohesive fra- 
mework of C++ classes, derivable from a single 
C++ Class, rather than API functions, as this al- 
lows derivation of functionality for specific 
needs. 

3. It provides a standard set of functions and a 
standard interface, regardless of the communica- 
tions protocol or remote platform environment. 

4. It internally implements platform / protocol 
specific features to maximise performance and 
minimise resource usage. 

5. It operates in an automatic, transparent man- 
ner to the user or using application. There is no 
need for the user to perform any action to estab- 
lish a communications 'session', or to activate 
the CSAE component. 

The main significance of these features is that a 
standard service and interface is provided across dif- 
ferent communications protocols and operating envir- 
onments, while optimising for each environment and 
allowing easy extensions to the provided services for 
specific needs. Normally, the problem when provid- 
ing 'generic' services is that you lose the ability to op- 
timise for specific environments or to 
change/enhance the functionality for specific appli- 
cation needs. 

The main use of the CSAE, as its name suggests, 
is to facilitate implementation of Client/Server appli- 
cations. In the preferred embodiment, it is directed to 
OS/2 as the client and MVS as the server, using 
APPC communications. This is probably the most 
complex environment to optimise for. As a result, cer- 
tain features are highlighted below as an example of 
the optimisation and functional tailoring that is possi- 
ble. It is important to keep in mind that the CSAE can 
be implemented for any platform. 

Functionality 

Remote Procedure Call (RPC) : The CSAE pro- 
vides a standard RPC mechanism. The client applica- 
tion provides the CSAE with the name of the remote 
function and a list of input and output parameters. The 
CSAE establishes the necessary communications, 
invokes the remote procedure and takes care of pro- 
viding its input parameters and returning the output 
parameters. Note that the remote procedure is in- 
voked through the standard mechanism for its envir- 
onment It does not know that it is being invoked 're- 
motely'. This means that existing functions can be 
used; they do not have to be specially written. 

The MVS server can invoke the remote proce- 
dure as a batch job, or as a sub-task of the Server 
CSAE component. As a sub task, the procedure can 
be either a statically linked module, or an independent 
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load module. Note that even if started as a batch job, 
the remote procedure can communicate with the cli- 
ent. 

Data Conversion : The CSAE provides parameter 
data types as C++ classes known as RemoteParm 
classes (described in detail later), which handle ail 
data conversion, and allow arbitrarily complex data 
structures to be built ie. arrays and structures, nest- 
ed to any depth. These classes accommodate DBCS 
data if operating under DBCS OS/2, and may accom- 
modate the following basic data types (new ones can 
readily be added): 

Fixed length character strings. 

Variable length character strings (any size). 

Unsigned short integers (2 bytes). 

Unsigned long integers (4 bytes). 

8 bit binary variables (bit strings, flags, etc) 

16 bit binary variables. 
The following composite data types are supported: 

Structures. 

Arrays (no pre-set size limit). 

Buffer Management The CSAE handles alloca- 
tion of memory for data buffers, both for sending data 
and returning data. The using application has no 
knowledge of the buffer sizes unless this information 
is requested. The data is packed into and extracted 
from the buffers by the RemoteParms. The interface 
between the CSAE and the application deals only 
with RemoteParms. There is no size limitation on the 
size of a RemoteParm object - if it exceeds the trans- 
mission buffer size it is transmitted in multiple sends. 
Note that the size of an array received by the client 
from the server has no pre-set size limit. Elements 
will be added to the array as necessary. 

File Management : Download and upload of files 
is provided. Aremote file can be downloaded to a local 
file, or just held in memory for browse/update. Data 
to be written to a remote file may be taken from a local 
file or memory. Both local and remote files can be 
created, extended, overwritten or deleted. Note that 
files with complex record structures, such as a mix- 
ture of character and binary data, repeating groups, 
DBCS, etc, can be transmitted, and will be converted 
as necessary between the local and remote formats. 

For MVS, PS (Physical sequential) datasets and 
PDS members can be sent/received. 

Transparent Operation : The CSAE communica- 
tions functions are contained in a Dynamic Link Libra- 
ry (DLL) that 'starts' when the first application re- 
quests these services, and 'stops' when the last ap- 
plication terminates. This not only provides these ser- 
vices in a transparent fashion, but also avoids repeat- 
ing the start-up overhead for the subsequent re- 
quests. By stopping as soon as no longer needed, re- 
sources are released as soon as possible. 

Flexibility: The CSAE provides timing and perfor- 
mance parameters that can be varied at run time for 
each using application, or even for differentf unctions 



within one application. Defaults are provided. 

As regards the problem of 'Performance & Re- 
source Use' (Currently OS/2 to MVS), the following 
features are provided: 

5 Concurrency : Concurrent requests are accom- 

modated up to the configured maximum permissible 
number of SNA sessions. Concurrency occurs on the 
PWS Client by having multiple applications, and/or 
multiple processes and threads within one applica- 

10 tion, request communications to a specific MVS ser- 
ver. All these requests are directed to a single client 
process, which manages the actual communications. 
On the MVS Server, two techniques are used: 

by attaching sub-tasks to the MVS Server 

15 CSAE address space, multiple requests can be han- 
dled by one MVS APPC address space; and 

by starting a batch job, for instance where the 
remote procedure needs a different 'environ- 
ment' than that of the MVS Server CSAE component 

20 (eg. STEPLIB, SYSUDUMP, etc). This offloads proc- 
essing to a batch region instead of the more 'expen- 
sive' APPC region. Note that this also limits the im- 
pact of one user to one APPC address space (schedu- 
ler). 

25 Session Control : The PWS CSAE contains man- 
agement functions that determine when to best allo- 
cate and deallocate conversations. This allows for re- 
source sharing and re-use where applicable. This al- 
lows these resources to be kept active if still needed, 

30 and cuts down on stopping and starting of conversa- 
tions, sessions, and the consequent scheduling of the 
Partner Object (this is described later). 

Resource Use : The aforementioned manage- 
ment of sessions and conversations, and the use of 

35 sub-tasks and batch regions makes maximum use of 
resources. 

Resource Sharing : The fact that one user can 
only schedule on APPC address space prevents one 
user from monopolising these resources. 
40 As regards the problem of 'Software Reuse & Ex- 
tensibility 1 , the following features are provided: 

Simplicity : The CSAE offers very straightfor- 
ward functions such as RPC, Send and Receive. This 
makes communications no more complex from the 
45 programming perspective than issuing a normal func- 
tion call. The underlying communications interface 
(ie. CPI-C / APPC) is not exposed. 

Functionally Extendable : The fact that the CSAE 
is a class means that it can be derived to allow 
so changes and extensions to its base functions. The 
communications system itself uses this concept by 
deriving a class to provide certain enhanced file man- 
agement functions. 

Environmentally Extendable : Although the pre- 
ss ferred embodiment of CSAE only accommodates 
OS/2 client and MVS server, all the partner specific 
code in the PWS CSAE is contained in a separate 
module. The CSAE can be easily extended to access 
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other server platforms by providing other platform 
specific modules, and the generic CSAE code can ac- 
cept future modules. 

The above described communications system of 
the preferred embodiment will now be illustrated fur- 
ther with reference to Figure 1 . The client computer 10 
has the IBM OS/2 operating system installed thereon, 
and an application program 40 runs on that operating • 
system. The application program will periodically re- 
quire communications services to be performed on 
the server computer 20 and/or data to be returned 
from the server 20 for subsequent use by the appli- 
cation program 40. For the purposes of the present in- 
vention it is irrelevant whether the requests for com- 
munications services to be carried out by the server 
are instigated by user interaction with the first appli- 
cation program 40, or whether the application pro- 
gram 40 operates independently of user interaction 
and makes the requests automatically during the run- 
ning of the program. 

When communications services are required 
from the server computer 20, the first application pro- 
gram informs the first logic means 50 of the service 
required. It may for example do this by sending the 
first logic means the name of a remote procedure 
along with a list of input and output parameters. The 
first logic means 50 then handles the task of estab- 
lishing the necessary communications with the sec- 
ond computer 20 with reference to definitions of the 
available communications services stored in the stor- 
age device 60. All the possible services are defined 
as a cohesive framework of object classes 70, these 
classes being derived from a single object class; as 
already described in detail above, defining the servic- 
es in this way gives rise to a great number of advan- 
tages in terms of performance and reusability. 

To establish the necessary communication with 
the server 20, the first logic means 50 determines 
which object class in the framework needs to be used, 
and then creates an instance of that object, a mes- 
sage being sent to that object so as to cause that ob- 
ject to invoke one of its methods. This gives rise to the 
establishment of the connection with the server com- 
puter via the connection means 80, and the subse- 
quent sending of a request to the second logic means 
90. 

The second logic means 90 then passes the re- 
quest on to the second application program 100 
(hereafter called the service application) running on 
the server computer 20 so that the service application 
1 00 can perform the specific task required by that re- 
quest, such as running a data retrieval procedure. 
Once this task has been completed the service appli- 
cation may need to send results back to the first com- 
puter 10. The server application 100 interacts with the 
second logic means 90 during the performance of the 
requested tasks and when results are to be sent back 
to the first computer 10. The second logic means 90 



establishes instances of objects, and invokes appro- 
priate methods of those objects, as and when re- 
quired by the server application 100, the object in- 
stances being created from the cohesive framework 

5 of object classes stored in the storage device 110. Ex- 
amples of the methods provided by the framework of 
object classes 120 is discussed later. 

Again the available communications techniques 
are defined as a cohesive framework of object class- 
to es 120 derived from a single object class in order to 
benefit from the advantages listed earlier. 

Using the above technique, the client application 
program 40 is not exposed to the communications ar- 
chitecture or communications API. Further the ser- 

15 vice application 100 is invoked through the standard 
mechanism for its environment; it does not know that 
it is being invoked remotely. 

The establishment of the communications servic- 
es as a cohesive framework of object classes will now 

20 be discussed. Once the idea of defining the services 
in this way has been derived, and it has been realised 
that this results in the many advantages discussed 
earlier, a skilled man in the art will typically be able 
to construct appropriate object classes. However, the 

25 following description illustrates one way in which the 
framework can be established. 

A class needs to be defined in the storage device 
60 for use by the first logic means 50 in order to im- 
plement the functions required by the client applica- 

30 tion 40. In the preferred embodiment this class will be 
referred to as the ClientPipe class. 

The ClientPipe class encapsulates the underly- 
ing communications functions and presents a simple 
model for invoking a remote procedure via APPC be- 

35 tween an OS/2 client and an MVS server. 

The ClientPipe class provides a synchronous 
RPC environment for a calling function. The Pipe is 
single threaded and offers no inbuilt concurrency pro- 
tection. 

40 An object of the ClientPipe class can be instanti- 
ated to provide a basic general purpose RPC facility. 
However, an application specific Pipe class can be 
derived from the ClientPipe class to provide improved 
and application specific functionality. 

45 The ClientPipe class has the following methods 
defined: 

A. Five public methods callable by the client ap- 
plication 40:- 

(1) a class constructor method; 
so (2) a class destructor method; 

(3) a method to invoke a remote procedure at 
a 'partner 1 object, which will be discussed lat- 
er;. 

(4) a method to convert parameters from the 
55 client PWS format to the Server host format; 

and 

(5) a method to convert parameters from the 
Server host format to the Client PWS format. 
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8. Three protected methods only callable by a de- 
rived Pipe class:- 

(1) a method to send data to the 'Partner* ob- 
ject - this represents the call part of the RPC 
architecture, and sends data to a named func- 
tion of the Partner; 

(2) a method -to receive data from the 'Part- 
ner 1 object - this receives data buffers from 
the Partner and returns these as parameters 
to the calling function (each parameter is en- 
capsulated as a RemoteParm object as de- 
scribed later); and 

(3) a method to delete a 'ConXn' object, for 
example when an error is returned from the 
Partner (the ConXn object will also be descri- 
bed later). 

C. Four methods which are internal to the Client- 
Pipe class:- 

(1) a method invoked when sending data to 
the Partner to convert ail input parameters 
and to build the appropriate control blocks in 
preparation for transmission to the Partner; 

(2) a method to receive and interpret a Trans- 
action Header sent by the partner 

(3) a 'C method implemented in a DLL which 
manages the creation of ConXn_Partner ob- 
jects and 'registers' a Pipe (represented by 
the connection means 80 in Figure 1) with the 
ConXn_Partner (the ConXn_Partner object is 
described later); 

(4) a 'C method implemented in a DLL 
which 'deregisters' a Pipe with a 
ConXn_Partner and deletes the 
ConXn_Partner if necessary. 

A corresponding class also needs to be defined 
in the storage device 110 for use by the second logic 
means 90 in order to implement the functions re- 
quired by the server application 1 00. In the preferred 
embodiment this will be referred to as the ServerPipe 
class. 

The ServerPipe class has the following methods 
defined: 

A. Six public methods callable by the server ap- 
plication:- 

(1) a method to handle the Control Conversa- 
tion - this is invoked whenever the server ap- 
plication is scheduled as the result of a Con- 
trol Conversation allocation; 

(2) a method to send data to the client comput- 
er 10, providing a standard subroutine mech- 
anism - it functions in the same way as the 
equivalent function in the ClientPipe class, 
data sent by this method being received by 
the client by use of the receiving method of the 
ClientPipe class; 

(3) a method to provide dynamic dataset allo- 
cation services; 

(4) a method to perform a dynamic load and 



call of an external load module; 

(5) a method to allocate and/or increase an 
area of storage used to hold the program va- 
riables for the currently executing function; 

5 and 

(6) a method to free up or reduce the above 
storage area. 

B. Three private methods internal to the Server- 
Pipe class:- 

10 (1) a method that operates as an asynchron- 

ous sub-task, and allocates a Data Conversa- 
tion with the Client ConXn_Partner. It re- 
ceives the data sent by the Client computer, 
and passes this to the Service application 1 00 

15 if appropriate; 

(2) a method for allocating storage for the data 
sent according to information supplied by the 
client computer, and to call and receive the 
data sent by the client; and 

20 (3) a method to disposition Server datasets 

on behalf of the Client computer 1 0. 

C. A number of user-written methods which need 
to be supplied by the user to complete the func- 
tionality of the service application 100:- 

25 (1 ) a method which is a user written d ispatch- 

er function, and invokes the appropriate user 
function requested by the client application 
40. This method is used to provide a standard 
interface into the application functions from 
30 the ServerPipe class, and is the external ref- 

erence which is resolved at link time; and 
(2) methods representing one or more user 
functions which may need to be invoked. 
The ConXn and ConXn_Partner classes referred 
35 to above will now be described. The Con_Xn class en- 
capsulates the underlying communications to the 
Partner. In the preferred embodiment, it provides the 
interface for all communications activity. It provides 
APPC communications to the MVS server computer 
40 20, but can be derived to use different communica- 
tions protocols (eg TCP/IP), and/or to communicate 
with other platforms. 

The Con_Xn class has the following methods 
callable by the client application program 40:- 
45 (1) a method which 'registers' with the 
ConXn_Partner to obtain a Data Conversation 
with the Partner; 

(2) a method which 'deregisters' with the 
ConXn_Partner to release the Data Conversation 

so with the Partner 

(3) a method for sending a buffer of data to the 
Partner; 

(4) a method for receiving a buffer of data from 
the Partner; 

55 (5) a method to confirm to the Partner that data 

has been received successfully - this is only done 
in response to a request for confirmation from the 
Partner, and 
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(6) a method to notify the Partner of an error - this 
can be done asynchronously or in response to a 
request for confirmation. 

The ConXn_Partner class encapsulates the Part- 
ner dependent information and functions, it imple- 
ments and controls the communications architecture 
of one Control Conversation and multiple Data Con- 
versations. The ConXn_Partner class ties together all 
Con_Xns that are accessing a particular client appli- 
cation for a particular user ID. Preferably the 
ConXn_Partner class is implemented in a DLL using 
runtime dynamic linking, and has the following meth- 
ods: 

A. Five public methods callable by the client ap- 
plication 40:- 

(1) a method invoked when the 
ConXn_Partner object is created -it initialises 
the data items and issues an APPLICA- 
TION_STARTED call; 

(2) a method invoked when the 
ConXn_Partner object is deleted -it issues an 
APPLICATION_ENDED call for the Control 
Conversation to terminate the APPC applica- 
tion; 

(3) a method which is invoked each time a 
Con_Xn object is created. It allocates or re- 
uses a Data Conversation for the Con_Xn as 
appropriate, and if necessary allocates the 
Control Conversation; 

(4) a method which is invoked each time a 
ConXn object is destroyed, to de-allocate or 
flag the Data Conversation as available, and 
if necessary de-allocate the Control Conver- 
sation; 

(5) a method to return the code page for the 
Partner. 

B. A Private method internal to the 
ConXn_Partner class which allocates the Control 
Conversation with the Partner. Security checks 
can be carried out as part of the allocation proc- 
ess. 

The RemoteParms mentioned earlier in the de- 
scription are defined as a class which forms the ab- 
stract base class for all parameters passed to a Cli- 
entPipe object for transmission to or from a remote 
function. It provides the means for passing arbitrarily 
complex data structures. A derived RemoteParm 
Class is created for each specific data type, which en- 
capsulates the data structure and thus knows how to 
convert its data from the client PWS format to the re- 
mote (partner) format. 

A RemoteParm object contains the data in both 
the local and remote formats. The local data is the ap- 
plication data, held for example as discontiguous data 
items. These are the data types such as integers, 
character strings, and abstract data types that are 
meaningful to the application. Member functions are 
provided to 'Get' and 'Puf these data items. The re- 



mote data is held in a contiguous buffer and consists 
of the converted local data plus the 'scaffolding* infor- 
mation needed for transmission and use by the re- 
mote function. This includes data such as the Eye- 

5 catcher (identifier) and the various length fields. 

The remote data buffer and functions to manipu- 
late it are* implemented in the base RemoteParm 
class, as these are generic. The local data items and 
their functions are implemented in the derived Remo- 

10 teParm class. 

The local data items are held as copies of the 
original data. Whenever local data is passed to the 
derived RemoteParm object, memory is allocated 
and the data is copied. This is because local data 

15 items 'belong' to the application. There should be no 
interdependency between the application and the Re- 
moteParm object for deleting the data, or re-using the 
memory containing the data. The remote data buffer 
belongs to the RemoteParm object. It is allocated and 

20 deleted via public member functions. 

The above described preferred embodiment of 
the present invention is much improved over the 
known prior communications systems for the follow- 
ing reasons: 

25 1. It provides additional services beyond RPC, 
such as the remote file manipulation and conver- 
sational capabilities; 

2. Being implemented as a cohesive framework 
of C++ object classes (derivable from a single 

30 class), it is easy to enhance the CSAE function- 
ality, rather than be restricted to the API provided; 

3. The CSAE is optimised to each operating en- 
vironment; 

4. The CSAE accepts and returns parameters, 
35 and dynamically allocates buffers for returned 

data; and 

5. The CSAE handles all conversion of data be- 
tween the two formats. 

By utilising the above-described approach in the 
40 construction of a programming interface for a com- 
munications system, a programmer of a client appli- 
cation can readily take advantage of the above- 
mentioned benefits derived from this approach. 
Further the communications Object Class 
45 is 'polymorphic', in that it can be viewed by different 
parts of the communication system as RPC, File 
Transfer, Send/Receive, a Data Converter, or any 
other communications service represented by the 
. Communication Object Class. 
so By providing these communications services as 
an Object Class rather than API functions, derivation 
of functionality for specific needs is possible. 

55 Claims 

1. A communications system for facilitating ex- 
change of data between a first computer (1 0) and 
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a second computer (20) connected in a network 
to operate in a client/server arrangement, the 
first computer (10) employing a different operat- 
ing system to the second computer (20), and the 
system having a basic communications applica- 5 
tion program interface (API), the system being 
characterised by: 

first logic means (50) for processing re- 
quests from a first application (40) running on the 
first computer (1 0) for connection with the second 1 o 
computer (20) to carry out one of a plurality of 
communication services; 

second logic means (90) for instructing a 
second application (100) on the second computer 
(20) to carry out the communications services is 
and for returning data provided by the second ap- 
plication (100) to the first computer (10); and 

a storage device (60, 110) on each com- 
puter accessible by the respective logic means 
(50, 90), each storage device storing a single ob- 20 
ject class for providing definitions for each of the 
plurality of communication services. 



employing a second logic means (90) to in- 
struct a second application (100) on the second 
computer (20) to carry out the communications 
services; 

returning data provided by the second ap- 
plication (1 00) via the second logic means (90) to 
the first computer; and 

storing in each computer in a storage re- 
gion (60, 110) accessible by the respective logic 
means (50, 90) a single object class for providing 
definitions for each of the plurality of communica- 
tion services. 

8. A method as claimed in Claim 7, wherein a cohe- 
sive framework of object classes (70, 120) de- 
rived from the single object class is stored in each 
storage region (60, 110). 

9. A method as claimed in Claim 8, wherein the 
communications services defined by the frame- 
work of object classes facilitate function calling, 
file manipulation, and data transfer. 



2. A system as claimed in Claim 1, wherein each 
storage device (60, 1 1 0) stores a cohesive frame- 25 
work of object classes (70, 1 20) derived from the 
single object class. 

3. Asystem as claimed in Claim 2, wherein the com- 
munications services defined by the framework 30 
of object classes facilitate function calling, file 
manipulation, and data transfer. 



4. A system as claimed in any of claims 1 to 3, 
wherein the operating system employed by the 35 
first computer is the IBM OS/2 operating system. 



5. A system as claimed in Claim 4, wherein the op- 
erating system employed by the second comput- 
er is the IBM MVS operating system. 40 



6. A system as claimed in any preceding claim, 
wherein the basic communications API is APPC. 



7. A method of operating a communication system 45 
to facilitate exchange of data between a first 
computer (10) and a second computer (20) con- 
nected in a network to operate in a client/server 
arrangement the first computer (1 0) employing a 
different operating system to the second comput- so 
er (20), and the system having a basic communi- 
cations application program interface (API), the 
method being characterised by the steps of: 

employing a first logic means (50) to proc- 
ess requests from a first application (40) running 55 
on the first computer (10) for connection with the 
second computer (20) to carry out one of a plur- 
ality of communication services; 
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